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A method and 
apparatus for establishing 
a voice call to a PSTN 
extension for a networked 
client computer, and routing 
the voice call off of the 
network, is provided. In 
a first embodiment, the 
apparatus comprises a 
storage medium having 
stored therein a plurality 
of programming instructions 
for implementing a set of 
communication services for 
facilitating establishment 
of the voice call to the 
PSTN extension, and an 
execution unit, coupled to 
the storage medium, for 
executing the plurality of 
programming instructions. 
The set of communication 
services include services for 
receiving a Push-To-Talk™ 
request from the networked 
client computer, requesting 
the voice call, and in 
response, determ i ning the 
PSTN extension. The 

Push-To-Talk*^ request includes identification information of an originating web server of the Push-To-Talk''''^ option, and the 
detemiination of the PSTN extension is made In accordance with the originating web server's identification information. 
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Method and Apparatus for Establishing a Voice Call 
To A PSTN Extension For A Networked Client Computer 

Background of the Invention 

1. Field of the Invention 

The present invention relates to the field of telecommunications and,, in particular, to a 
method and apparatus for establishing a voice call to a Public Switching Telephone Network 
(PSTN) extension for a networked client computer. 

2. Background Information 

Numerous advances have been made in recent years in the field of 
telecommunications. In particular, the field of internet telephony has emerged as a viable 
technology that is evolving at an ever increasing rate. Evidence of this evolution of internet 
telephony is best characterized by the number of new products recently become available in 
the market. Products such as CoolTalk by Netscape Communications Corporation of 
Mountain View, California; Internet Connection Phone by International Business Machines 
of Amonk, New York; Intel Internet Phone (IPhone) by Intel Corporation of Santa Clara, 
California; NetMeeting by Microsoft Corporation, Redmond, Washington; Quarterdeck 
WebTalk by Quarterdeck Corporation of Marina Del Rey, California; TeleVox by Voxware 
Incorporated of Princeton, New Jersey; and WebPhone by Netspeak Corporation of Boca 
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Ralon, Florida, are representative of the current state of applications facilitating interent 
telephony. 

Each of these products offers internet based voice communications with a telephone 
motif, between two users each using the same (or compatible) product on either end of the 
internet connection. That is, the internet provides the "switching" architecture for the system, 
while the computer acts as the "handset", or the audio interface. One reason for the 
proliferation of these applications is a desire to push the technology of the internet to provide 
a total communications tool. The appeal to users is that, currently, the use of the internet is 
free of toll charges. Therefore, currently, a user of an internet phone product may 
communicate with another user located anywhere else in the world v^thout having to pay the 
long distance charges associated with making a telephone call using the public switched 
telephone network (PSTN). 

However, consumers expecting to completely eliminate their long-distance telephone 
bills through the exclusive use of internet telephony are in for a disappointment. As they 
shall soon discover, although innovative in their own right, the current internet based 
telephony applications identified above have a number of limitations which retard their 
acceptance as a primary communications tool. One such limitation is that many of the 
applications identified above require that both users have installed the same software 
package, or compatible packages and, therefore, provide a relatively low level of 
interoperability. One reason for this lack of interoperability between internet telephony 
applications is that the developers of many of these products have incorporated different 
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voice encoders (commonly referred to as a "voice codec", or simply a "codec" by those in the 
telecommunication arts) in the products. Consequently, as a result of the different codecs 
used, many internet telephony applications are unable to recognize speech encoded (i.e., 
digitized) by a codec of a disimilar application. 

This problem is alleviated for those products that are upgraded to comply with 
emerging telephony standards, such as International Telecommunication Union's (ITU) H.323 
standard. However, other limitations remain. For example, another limitation associated 
with many of these products is that they are tied to the internet, often requiring all users to 
access a common server in order to maintain a directory of available users in which to call. 
That is to say, many of the applications identified above do not integrate the packet switched 
network of the internet with the circuit switched public switched telephone network (PSTN). 
Therefore, although a computer connected to the internet may communicate with another user 
on the internet, assuming they are both using a common software application (or at least 
applications with compatible codecs), these applications do not support communication with 
a user of a Telephone handset. 

The reason for this limitation is readily understood by those who appreciate the 
complexity of the two networks. As alluded to above, the internet is a packet switched 
network. That is to say, communication over the internet is accomplished by "breaking" the 
transmitted data into varying-sized packages (or "packets"), based primarily on 
communication content, and interleaving the various-sized packages to best utilize the 
bandwidth available at any given time on the internet. When the packets reach their intended 
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destination, they must be reassembled into the originally transmitted data. Loss of packets, 
and thus data, occur frequently in such a network, and the ability of the network to 
succesfuUy transmit information from one point in the network to another determines the 
quality of the network. For inter-computer communication transactions involving non real- 
time data, the ability to transmit packets and retransmit any packets that are perceived to have 
been dropped is not a severe limitation and may not even be perceived by the user of the 
system. However, in a voice communication transaction, the delay required to retransmit 
even one data packet may be perceived by a user. At best, such delays are an annoying 
inconvenience. In practice, the delays actually can become intolerable, as the cumulative 
latency adds up with successive transmissions. 

In contrast to the packet switched network of the internet, the public switched 
telephone network (PSTN) is a circuit switched network. That is to say that the PSTN 
assigns a dedicated communication line to a user with which to complete the telephone call, 
wherein the user can utilize the assigned resource of the PSTN in any way they choose, with 
the understanding that the user is paying for the use of the dedicated resource of the PSTN. 
While the circuit switched approach of the PSTN system is not necessarily the most efficient 
system in terms of call traffic (i.e., it does not make use of the "dead space" common in a 
conversation), it is relatively easy to ensure that information destined for a particular user is 
delivered, it simply provides a dedicated line to complete the transaction. 

Nonetheless, despite these engineering challanges, a few products have emerged 
which purport to integrate the PSTN to the internet. Products such as Net2Phone by IDT 



wo 98/41032 5 PCT/US98/04975 

Corporation of Hackensack, New Jersey, claim to provide a computer user with the ability to 
place and receive a phone call to/from a PSTN extension. Unfortunately, none of these 
products completely solve the problem of integrating the two networks. The limitations 
perhaps best characterized by way of an example communication session. With these prior 
art internet telephony applications, a user of an internet telephony enabled client computer 
initiating a telephone call to a Telephone handset launches the voice call from the client 
computer by accessing a server (the primary access server), operated by the developer of the 
internet telephony application that supports internet telecommunications. As the initiator 
accesses the primary access server, he/she is prompted for a destination address, which takes 
the form of a PSTN telephone number for an outgoing call to a Telephone handset. Having 
provided the primary access server with the PSTN telephone number associated with the 
Telephone handset, the primary server somehow determines* which server in a community of 
similarly enabled servers (i.e., servers with the hardware/software necessary to provide access 
to the PSTN) is closest to the destination address, and completes the telephone call by routing 
the telephone call through a number of intermediate servers on the internet to the selected 
server, which will actually place the voice call to the Telephone handset on behalf of the 
client computer, facilitating the voice call between the client computer and the Telephone 
handset. In other words, the user of the client computer is required to have prior knowledge 
of the destination phone number, which is limiting in many circumstances. For example, in a 
situation where the user of the client computer is engaged in a data conamunication session 
involving a webpage for a corporate entity, the user may wish to speak with someone in a 
"local office" of the corporate entity. Prior art internet telephony applications require that the 

* The manner in which the " primary access server" determines the " call originating server" is not known. 
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telephone number for the "local office" of the corporate entity be provided by the user of the 
client computer hi order to place the telephone call. If the telephone number for the "local 
office" of the corporate entity is not provided by the webpage, the user of client computer 
must look it up or have prior knowledge of it. 

Additionally, while the prior art approach of simply finding the internet telephony 
enabled server closest to the destination address may offer the simplest technical solution and 
a seemingly cheaper connection, it does not ensure the quality of the voice connection. One 
skilled in the art will appreciate that there are a number of characteristics which may impact 
the quality of the voice connection. For example, insofar as the internet is a packet switched 
network, as the number of intermediate routers required to interface the client computer to the 
selected server increases so, too, does the likelihood that data packets containing voice 
information could be lost or corrupted. The result of lost or corrupted data packets is broken 
or garbled speech. Another factor affecting internet telephony communication performance is 
the bandwidth available on the selected server. If, for example, the selected server is very 
busy handling a number of other processes, the performance associated mth each of the 
processes begins to degrade (i.e., slow down), which may also result in delayed delivery of 
data packets containing speech, which in turn results in user perception of poor quality. 
Therefore, while it is important to some users of internet telephony applications to simply 
keep the cost down, quality considerations must also be accounted for to enable internet 
telephony to evolve into a viable communications tool. 
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Thus, a need exists for a method and apparatus for establishing a voice call to a PSTN 
extension for a networked client computer that is unencumbered by the limitations associated 
with the prior art. 

Summary of the Invention 

In accordance with the teachings of the present invention, a method and apparatus for 
establishing a voice call to a PSTN extension for a networked client computer, and routing 
the voice call off of the network, is provided. In a first embodiment, the apparatus comprises 
a storage medium having stored therein a plurality of programming instructions for 
implementing a set of communication services for facilitating establishment of the voice call 
to the PSTN extension, and an execution unit, coupled to the storage medium, for executing 
the plurality of programming instructions. The set of communication ser\'ices include 
services for receiving a Push-To-TalkTM2 event notification from the networked client 
computer, notifying of client computer's desire to have voice communication, and in 
response, determining the PSTN extension. The Push-To-Talk^w event notification includes 
identification information of an originating web server of the Push-To-Talk™ option, and the 
determination of the PSTN extension is made in accordance with the originating web server's 
identification information. 

In another embodiment, the set of communication services further include services for 
providing the client computer with the IP address of the apparatus, and receiving a 
supplemental call request from the client computer. The supplemental call request includes 
the IP address, telephony and geographical information of the client computer, and the 
determination of the PSTN extension is also made in accordance with the telephony and/or 
geographical information of the client computer. 



^ Push-To-TalkTM is a Trademark of eFusionTM^ Incorporated of Beaverton, Oregon. 
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In yet another embodiment, the set of coniniunicalion services further include services 
for soliciting inputs from one or more other apparatuses on one or more operating 
characteristics associated with establishing and facilitating the voice call between the client 
computer and the PSTN extension, selecting either the apparatus itself or one of the other 
apparatuses to complete the telephone call based on the solicited inputs, registering the voice 
call with the selected apparatus, and identifying the selected apparatus to the client computer. 

In yet another embodiment, the set of communication services further include services 
for accepting registration of the voice call, receiving placement of a net phone call from the 
client computer, placing a PSTN phone call to the PSTN extension, and bridging the net and 
the PSTN phone calls. The bridging services include services for converting and delivering 
call signals between the client computer and the telephone handset. 

Brief Description of the Drawings 

The present invention will be described by way of exemplary embodiments, but not 
limitations, illustrated in the accompanying drav^ngs in which like references denote similar 
elements, and in which: 

Figure 1 is a block diagram illustrating an exemplary communication system 
incorporating the teachings of the present invention; 

Figures 2 A and 2B are flow charts illustrating one embodiment of a method for 
establishing a voice communication session between a client computer and a PSTN handset, 
in accordance with one embodiment of the present invention; 

Figure 2C is a flow chart illustrating one embodiment of a method for establishing a 
direct telephony connection between the client computer and the exemplary communication 
system; 
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Figure 3 is a block diagram illustrating an exemplary computer server incorporating 
the teachings of the present invention; 

Figure 4 is a block diagram illustrating the software architecture of the exemplary 
server of Figure 3, in accordance with one embodiment of the present invention; and 

Figures 5, 6 and 7 are graphical illustrations of alternate embodiments of Push-To- 
Talk™ indicators for requesting a voice communication session, suitable for use in the 
exemplary communication system described in Figures 1-4. 

Detailed Description 

In the following description, for purposes of explanation, specific numbers, materials 
and configurations are set forth in order to provide a thorough understanding of the present 
invention. However, it will be apparent to one skilled in the art that the present invention 
may be practiced without the specific details. In other instances, well known features are 
omitted or simplified in order not to obscure the present invention. Furthermore, for ease of 
understanding, certain method steps are delineated as separate steps, however, these 
separately delineated steps should not be construed as necessarily order dependent in their 
performance. 

Referring now to Figure 1, a block diagram is presented illustrating an exemplary 
communication system 100 incorporating the teachings of the present invention for 
connecting a user of an internet telephony enabled client computer wdth a user of a PSTN 
endpoint (e.g., telephone handset), and routing the voice call off of the internet. While the 
present invention will be described in the context of this exemplary computer system, based 
on the descriptions to follow, those skilled in the art wall appreciate that the present invention 
is not limited to this embodiment, and may be also practiced with intranet (in lieu of the 
internet) and/or automated/computerized telephony answering equipment (in lieu of 
telephone handsets). 
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For the illustrated embodiment, client computer 102 incorporated with the teachings 
of the present invention, while in data communication with a web server, e.g. web server 128, 
through PSTN 140 and Internet 150, is presented with a Push-To-Talk™ option by web 
server 128. When client computer 102 selects the Push-To-Talk™ option, a server 
incorporated with the teachings of the present invention (e.g., bridgeport 162) automatically 
determines an appropriate destination PSTN extension, e.g. the PSTN extension of telephone 
handset 142, as well as an appropriate one of the community of internet/PSTN changeover 
servers (e.g., bridgeports 162 and 165) to place the voice call to the PSTN extension and 
facilitate the voicei call between the user of client computer 102 and the user of a PSTN 
endpoint (e.g., handset 142). In the context of the example embodiment, for differentiation 
and ease of explanation, bridgeport 162 will be referred to as a page bridgeport, while the 
selected internet/PSTN changeover server (e.g., bridgeport 165) will be referred to as a 
changeover bridgeport. In one embodiment, the Push-To-Talk'^^ option is pre-associated 
with bridgeport 162 by web server 128, and the determination of the destination PSTN 
extension by bridgeport 162 is made in accordance with one or more attributes of web server 
128, such as the identity of web server 128, and optionally, one or more attributes of client 
computer 102, such as the zip code of the area client computer 102 is located. In alternate 
embodiments, page bridgeport 162 is not pre-associated with the Push-To-Talk™ option, but 
rather is selected dynamically by web server 128 

Client computer 102, web servers 120 and 128, bridgeports 162 and 165, and handset 
142 are communicatively coupled to each other by way of PSTN 140 and internet 150 as 
shown. More specifically, client computer 102 is coupled to internet 150 by way of a direct 
connection to internet service provider (ISP) 112. Client computer 102 is coupled to ISP 112 
through PSTN extension 104, communication line 106 and PSTN 140. In other words, for 
the illustrated embodiment, client computer 102 includes a modulation/demodulation 
(MODEM) device (not shown) coupled to PSTN extension 104. However, a client computer 
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may be coupled to ISl^ 112 through a network connection using a network interface instead, 
such as client computer 108 using network connection 110, Alternatively, a client computer 
may also be directly coupled to internet 150 such as client computer 116 using direct 
connection 118. 

Web servers 120 and 128 are coupled to internet 150 through connections 122 and 
130. Although not illustrated, web servers 120 and 128 may also be coupled to PSTN 140. 
Similarly, bridgeports 162 and 165 of the present invention are coupled to internet 150 
through connections 164 and 167. Bridgeports 162 and 165 are also coupled to PSTN 140 
through communication lines 163 and 166 respectively. Handset 142 is coupled to PSTN 140 
through PSTN extension 143 and communication line 144. 

Communication lines 106, 115 and 144 may simply be plain old telephone service 
(POTS) communication lines, although other types of communication lines may be used. For 
example, in the case of communication line 106, it may be an integrated service digital 
network (ISDN) line, whereas in the case of communication line 115, it may be a Tl (1.533 
Mbps) or an El (2.0488 Mbps) trunk line. In the case of communication line 144, it may be a 
wireless cellular connection, a Personal Communications Services (PCS) connection, and the 
like. 

PSTN 140 includes a number of Service Switching Points (SSP), Signal Transfer 
Points (STP), and Service Control Points (SCP) coupled to each other (not shown). PSTN 
extension 104 through communication line 106 is coupled to a "local" SSP, which in turn is 
coupled to a number of other "local" PSTN extensions, including e.g. PSTN extension 113 if 
ISP 112 is a "local" ISP served by the same SSP. In addition, the "local" SSP is also coupled 
to an associated STP, which in turn is coupled to other "remote" SSPs. Each of the "remote" 
SSPs is coupled to a number of "remote" PSTN extensions, including e.g. extension 143, if 
handset 142 is a "remote" handset served by a "remote" SSP. As is well known in the art, 
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inlernel 150 includes a number of networks interconnected by routers, interconnecting the 
various client computers, web servers and bridgeports together. [As described earlier, 
internet 150 may be a private intranet instead.] 

Except for the incorporated teachings of the present invention (to be more fully 
described below), client computer 102 is intended to represent a broad category of internet 
telephony enabled computer systems known in the art. An example of such a computer 
system is a desktop computer system equipped with a high performance microprocessor, such 
as the Pentium® processor manufactured by Intel Corporation of Santa Clara, CA or the 
Alpha® processor manufactured by Digital Equipment Corporation of Manard, MA; a 
number of audio input and output peripherals/interface for inputting, digitizing and 
compressing outbound audio, and for decompressing and rendering inbound audio; a 
communication interface for sending and receiving various data packets (including audio data 
packets) in accordance with certain standard communication protocol, such as a V.42bis 
compliant modem or an Ethernet adapter card; a windows-based operating system including 
internetworking communication services providing support for Transmission Control 
Protocol/Internet Protocol (TCP/IP) (and other Internet Communication Suite protocols) and 
socket services , such as Windows™ 95 developed by Microsoft Corporation of Redmond, 
WA; a web communications tool such as Navigator*^^, developed by Netscape 
Communications of Mountain View, CA; and an internet telephony application, such as the 
above described IPhone™^ developed by Intel Corporation. 

In one embodiment, the teachings of the present invention are incorporated in client 
computer 102 in the form of a client application. In one embodiment, the client application is 
a bridgeport driver. The client bridgeport driver may be made available to client computer 
102 in a number of alternate means. For example, the client bridgeport driver may be 



' Note that it is not necessary for the internet telephony application to explicitly support voice calls with 
telephone handsets, as is the case with IPhone and many of the prior art internet telephony applications. 
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distributed via diskettes produced by a bridgeport vendor, or downloaded from a web server 
of the bridgeport vendor. In other embodiments, the teachings of the present invention are 
incorporated in the browser and/or the operating system (OS) of cHent computer 102. For 
ease of understanding, the remaining descriptions will be presented in the context of the client 
bridgeport driver embodiment. 

Except for the presentation of webpages having Push-To-Talk'^'^ options pre- 
associated with the bridgeports of the present invention, web servers 120 and 128 are 
intended to represent a broad category of web servers, including e.g. corporate presence 
servers and government presence servers, known in the art. Any number of high performance 
computer servers may be employed as web servers 120 and 128, e.g. a computer server 
equipped with one or more Pentium® Pro processors from Intel Corp., running Mircrosoft's 
Windows® NT operating system, or a computer server equipped with one or more SPARC® 
processors from Sun Microsystems of Mountain View, CA, running Sun's Solaris® operating 
system. 

Similarly, ISP 112 is intended to represent a broad category of internet service 
providers. An ISP may be a "small" local internet access provider, or one of a number of 
point of presence providers offered by a "large" ISP. It is also anticipated that ISP 112 may 
be incorporated with an SSP of PSTN 140. Handset 142 is intended to represent a broad 
category of conventional handsets knovm in the art, including but not limited to desktop 
handsets, cordless handsets, and wireless handsets. No special features are required of 
handset 142 for it to be called and connected to internet telephony enabled client computer 
102, in accordance with the present invention. [As described earlier, handset 142 may also be 
automated/computerized telephony answering equipment.] 

Before we proceed to describe bridgeports 162 and 165 in further detail, it should be 
noted that one skilled in the art of, for example, telecommunications, will appreciate that the 
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communication system illustrated in Figure 1, is significantly more complex than thai which 
is depicted. For example, each SSP of PSTN 140 may service thousands of PSTN 
extensions, and there are numerous SSPs, STPs and SCPs in a common PSTN 
implementation. Internet 150 includes well over several hundred thousand networks. 
Together, PSTN 140 and internet 150 interconnect millions of client computers and web 
servers. Nonetheless, Figure 1 does capture a number of the more relevant components of a 
communication system necessary to illustrate the interrelationship between client computer 
102, web server 128, bridgeports 162 and 168, and handset 142, such that one skilled in the 
art may practice the present invention. Also, while the present invention is being described in 
the context of client computer 102 being engaged in data communication with web server 
128, as will be readily apparent from the description to follow, the present invention may be 
practiced with any "client" computer engaged in data communication with any "web" or 
"info" server. 

Turning now to Figure 2 A, a flow chart illustrating one embodiment of the method 
steps of the present invention for establishing and facilitating a voice call to a PSTN 
extension for a networked client computer is shown. For ease of explanation, the method of 
Figures 2A-2C will be developed in the context of an example implementation, wherein a 
user of client computer 102 is engaged in a data communication session involving a webpage, 
projected by web server 128, which incorporates a Push-To-Talk™ feature wherein the user 
of the webpage may "push" a displayed Push-To-Talk™ button to cause a voice cormection 
to be established with a local office, retail center and the like, associated with the web server, 
enabling the user of client computer 102 to engage in a voice call with a user of a PSTN 
endpoint (e.g., handset 142) located at the "local office". [Those skilled in the art will 
appreciate that the terms "push" and "pushing" are metaphoric descriptions of the action taken 
by a user of the client computer. The action is in actuality accomplished, e.g., by the user 
clicking a mouse button, upon moving a cursor over the displayed Push-To-Talk™ button.] 
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With reference lo Figure 2 A, the method begins at step 202 with a user of client 
computer 102 "pushing" the Push-To-Talk™ button projected with the webpage. As 
described earlier, the Push-To-Talk™ button is pre-associated with a bridgeport, e.g., page 
bridgeport 162. In one embodiment, the pre-association is accomplished via HyperText 
Markup Language (HTML) elements embedded in the webpage, identifying the Uniform 
Resource Locator (URL) of bridgeport 162. The HTML elements further specify that a Push- 
To-Talk™ event notice including the URL of web server 128 is to be posted to page 
bridgeport 162. Thus, in response to the user's "pushing" of the Push-To-Talk™ button, a 
HyperText Transmission Protocol (HTTP) connection is temporarily established between 
client computer 102 and page bridgeport 162, and a message posting the Push-To-Talk™ 
event is sent to page bridgeport 162. 

For the illustrated embodiment, in response to the Push-To-Talk™ event notification, 
page bridgeport 162 identifies itself to client computer 102, providing client computer 102 
with its internet protocol (IP) address, step 204. The HTTP connection is closed upon 
sending the return data to client computer 102 by page bridgeport 162. In one embodiment, 
the identification and provision of page bridgeport's IP address also includes identification 
that the information is associated with a Push-To-Talk™ button projected by web server 128. 
More specifically, the URL of web server 128 is also returned to client computer 102. For 
the illustrated embodiment, the returned data also includes a command for starting up the 
client bridgeport driver on client computer 102. 

Next, for the illustrated embodiment, client computer 102 identifies itself to page 
bridgeport 162, providing page bridgeport 162 with its IP address and attributes. For the 
illustrated embodiment, the identification is performed by the launched client bridgeport 
driver, by way of another HTTP connection. In one embodiment, the identification is also 
made in the form of a call request to talk to a person, such as an agent, associated with web 
server 128. In one embodiment, the attribute information includes a zip code for the area 
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clicnl computer 102 is located. In another embodiment, the attribute information includes a 
PSTN extension associated with client computer 102. In one embodiment, the URL of web 
server 128 is also re-transmitted. 

In response, page bridgeport 162 determines a destination PSTN extension for the 
requested call, step 208. In one embodiment, the determination is based on attributes of web 
server 162, e.g. the URL or the associated corporate name (if provided) of web server 162. In 
another embodiment, the determination is also based on attributes of client computer 102, e.g. 
the 2ip code or the telephone area code/prefix associated with client computer 102. In one 
embodiment, page bridgeport 162 is equipped with a PSTN extension database having the 
necessary attributes and PSTN extension information for performing the determination. In an 
alternate embodiment, page bridgeport 162 is not equipped with such a PSTN extension 
database, but equipped with services that access external on-line services (e.g., geographic 
location services, directory services, etc.) to make the determination. An example of an on- 
Ibe geographic service is MapBlast™, developed by Vicinity Corporation of Palo Alto, CA. 

Upon determining the destination PSTN extension, for the illustrated embodiment, 
page bridgeport 162 selects an internet/PSTN changeover server. In one embodiment, the 
internet/PSTN changeover server is a bridgeport, such as bridgeport 165 (hereafter, 
changeover bridgeport), where the requested voice call would be routed off internet ISO and 
onto PSTN 140, step 210. The selection is made from a "community" of bridgeports, to be 
described more fially below. In one embodiment, the "community" of bridgeports are 
"private" bridgeports deployed by the corporation of web server 128. In another embodiment, 
the "community" of bridgeports are "public" bridgeports deployed by a service company that 
offers "bridgeport" service of the present invention, and subscribed by the corporation of web 
server 128. Note that page bridgeport 162 may select itself as the changeover bridgeport, 
either because of the selection criteria employed dictate the result, or by virtue of a singleton 
community, i.e., page bridgeport 162 is the only bridgeport of the "community". For ease of 
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understanding, the remaining descriptions will be presented in the context of bridgeport 165 
being the selected changeover bridgeport. 

Upon selecting changeover bridgeport 165, for the illustrated embodiment, page 
bridgeport 162 registers the requested call with changeover bridgeport 165, step 210. In one 
embodiment, the registration reserves bandwidth on changeover bridgeport 165 for the 
requested call. In one embodiment, the registration includes provision of the source IP 
address of the voice call, i.e., the IP address of client computer 102, the source type (e.g. 
H.323), the destination address, i.e. the destination PSTN extension of handset 142, and the 
destination type (e.g. POTS). 

Next, for the illustrated embodiment, page bridgeport 162 identifies changeover 
bridgeport 165 to client computer 102, providing client computer 102 with the IP address of 
hop off bridgeport 165, step 212. In one embodiment, where the call request is made through 
an HTTP connection, step 212 also includes closing the HTTP connection. In one 
embodiment, the identification also includes provision of the URL of web server 128. In one 
embodiment, both the identification, i.e., the IP address of changeover bridgeport 165, and 
the URL of web server 128 are provided to client bridgeport driver. 

Next, for the illustrated embodiment, client computer 102 places a net call to 
changeover bridgeport 165, step 214. In one embodiment, the net call is an H.323 call placed 
by an internet telephony application. In one embodiment, step 214 also includes automatic 
launching of the internet telephony application to place the net call, if an internet telephony 
application has not been previously launched. For the illustrated embodiment, the automatic 
launching is performed by the client bridgeport driver. 

In response, changeover bridgeport 165 places a voice call to the PSTN extension of 
handset 142, and bridges the net and the voice calls, step 216, thereby allowing a user of 
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client computer 102 to communicate with a user of handset 142. In bridging the two calls, 
changeover bridgeport 165 digitizes and compresses inbound call signals received from 
handset 142, and delivers the encoded call signals to client computer 102 via the previously 
established H.323 connection. The compressed inbound call signals are decompressed by the 
communication interface of client computer 102 and rendered by the internet telephony 
application. Similarly, outbound call signals emanating from client computer 102 are 
digitized by the audio interface, compressed by the communication interface of client 
computer 102 and delivered to changeover bridgeport 165 via the H.323 connection, wherein 
they are decompressed, and upon conversion, forwarded to handset 142. In other words, 
changeover bridgeport 165 converts the voice information between PSTN and IP protocols 
and delivers voice call information to/from handset 142 and client computer 102 until call 
completion. 

With reference now being made to Figure 2B, one embodiment of step 216 is 
illustrated. As the H,323 connection between client computer 102 and changeover bridgeport 
165 is established, changeover bridgeport 165 determines if a direct connection with client 
computer 102 is to be established, if client computer 102 and changeover bridgeport 165 are 
not in direct connection with each other. If changeover bridgeport 165 makes the 
determination not to establish a direct connection between client computer 102 and itself, 
changeover bridgeport 165 establishes and facilitates the voice call to PSTN extension 143 as 
described earlier, in step 230. Additionally, in those cases where changeover bridgeport 165 
is not in direct telephony contact with client computer 102, (i.e., the call is being routed 
through a number of intermediate servers throughout Internet 150), changeover bridgeport 
165 also monitors the "quality" of the voice call. Any number of metrics known in the art 
may be beneficially employed to measure the quality of the voice call, e.g. the number of 
audio packets dropped within a predetermined time interval (Packet Error Rate), the signal to 
noise ratio, the rise in the measured noise floor, and the like. 
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If quality of the voice call is not monitored and the voice call has not been completed, 
steps 232 - 234, changeover bridgeport 165 returns to step 230. However, if quality of the 
voice call is monitored, step 232, changeover bridgeport 165 further determines if the quality 
has reached a predetermined threshold and, in addition, whether the user of client computer 
102 has previously rejected an offer to switch to a direct telephony connection with 
changeover bridgeport 165, step 236. If the measured quality level is in an acceptable range, 
or the user has previously rejected an offer to establish a direct connection, changeover 
bridgeport 165 returns to step 230. Otherwise, changeover bridgeport 165 prompts the user 
as to whether the user would like to switch to a direct telephony connection between client 
computer 102 and changeover bridgeport 165, step 238. If the user responds with an election 
not to switch to a direct telephony connection, step 240, changeover bridgeport 165 returns to 
step 230. However, if the user responds with an election to switch to a direct telephony 
connection, step 240, changeover bridgeport 165 causes a direct telephony connection to be 
established between itself and client computer 102, step 242. Upon establishing the direct 
telephony connection, changeover bridgeport 165 continues to facilitate the voice call as 
described earlier, step 230. 

Similarly, if back in step 228, changeover bridgeport 165 makes the determination to 
establish a direct connection between client computer 102 and itself, the process proceeds to 
step 238 wherein the user of client computer 102 is offered the opportunity to accept or 
decline to establish a direct connection between client computer 102 and changeover 
bridgeport 165. From step 238, the process proceeds as described earlier. Whether 
changeover bridgeport 165 proceeds to step 230 or to step 238 directly from step 228 will be 
described in more detail below. 

Turning now to Figure 2C, a flow chart illustrating one embodiment of a method for 
establishing a direct telephony connection between client computer 102 and the PSTN 
extension associated with handset 142. In the context of the illustrated embodiment. 
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changeover bridgeport 165 provides a software lo client computer 102, step 250. The 
software is a set of instructions containing information necessary to enable client computer 
102 to establish a direct telephony connection with changeover bridgeport 165. Upon receipt 
of the software by client computer 102, the software tears down the existing connection 
between client computer 102 and the ISP currently in direct telephony contact with client 
computer 102 (e.g., ISP 112), step 252. Having disconnected the prior connection, the 
provided software initiates a direct telephony connection to changeover bridgeport 165 
through the modem of client computer 102, thereby eliminating any intermediate servers, step 
254. For the illustrated embodiment, the software is "equipped" with one of changeover 
bridgeport's PSTN extensions before being provided to client computer 102. Finally, once 
the direct telephony connection from client computer 102 is established, changeover 
bridgeport 165 logically "re-links" client computer 102 with the PSTN extension of handset 
142, step 256, thereby allowing the previously established voice call to be re-connected 
(although, it should be noted that the physical PSTN connection between the changeover 
bridgeport and the PSTN extension is never disconnected; rather, it is the data connection 
between the client computer and the changeover bridgeport that is disconnected in favor of a 
direct telephony connection). In an alternate embodiment, the direct connect software may be 
pre-installed on client computer 102, e.g. as part of client bridgeport application described 
earlier. 

Returning now to step 228 of Figure 2B, in one embodiment, changeover bridgeport 
165 proceeds to step 238 directly, without first monitoring the quality of the voice call, if the 
changeover bridgeport 165 "knows" a priori that the quality of the voice call will be below an 
acceptable threshold. For example, assume that it has been determined that the quality of a 
voice call drops below a predetermined quality level when the number of intermediate servers 
between a client computer (e.g., client computer 102) and a changeover bridgeport (e.g., 
changeover bridgeport 165) exceeds a certain number Nj. Given this example, 
notwithstanding the fact that changeover bridgeport 165 was originally selected as the "best" 
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changeover bridgeporl from the "community" of bridgeports, if the actual number of 
intermediate servers N, between cHent computer 102 and changeover bridgeport 165 exceeds 
N2, changeover bridgeport 165 will kjiow, before the voice call has been established, that the 
quality of the voice call will be below the acceptable predetermined quality level. In one 
embodiment, the number of intermediate servers is returned to changeover bridgeport 165 
when page bridgeport 162 selects bridgeport 165 as the changeover bridgeport and registers 
the voice call with changeover bridgeport 165. In one embodiment, changeover bridgeport 
165 preserves the inputs along with the registration information for use at step 228. In 
another embodiment, bridgeport 165 may retain up to a predetermined number of "bid 
responses", which will include the number of intermediate servers, for a period of time 
sufficiently long to ensure that if bridgeport 165 is selected as the changeover bridgeport, the 
bid response information is available. 

In an alternate embodiment, changeover bridgeport 165 proceeds to step 238 directly, 
without having first monitored the quality of the voice call, if changeover bridgeport 165 was 
instructed to do so by page bridgeport 162 when page bridgeport 162 selects bridgeport 165 
as the changeover bridgeport and registers the voice call. Page bridgeport 162 may select to 
so instruct changeover bridgeport 165, based on a similar decision process described earlier 
for the case where changeover bridgeport 165 makes the decision. Alternatively, page 
bridgeport 162 may do so because it is so instructed by web server 128, through parameters 
embedded within the Push-To-Talk^M button. In other words, the Push-To-TalkTw button, 
projected by web server 128, may be a "direct quality" Push-To-Talk™ button that inherently 
includes offering the user of client computer 102 with the option to conduct the voice call via 
a direct connection at a "direct quality" level. 

In summary, page bridgeport 162, in response to a Push-To-Talk™ event notification, 
solicits inputs and selects a changeover bridgeport (e.g., bridgeport 165) from a "community" 
of bridgeports. Changeover bridgeport 165, in response to the placement of a net call fi-om 
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client computer 102, establishes a PSTN connection to the appropriate PSTN extension and 
bridges the call. In so doing, client computer 102 may be offered to have the voice call 
conducted at a "direct quality" level via a direct connection between client computer 102 and 
changeover bridgeport 165. The offer may be presented dynamically in the middle of the 
call, at the discretion of changeover bridgeport 165 as it detects the quality of the voice call 
dropping below an predetermined quality level. Alternatively, the offer may be presented at 
the beginning of the voice call, at the discretion of changeover bridgeport 165, page 
bridgeport 162 or web server 128. 

Note that except for the solicitation of the concurrence of the user of client computer 
102 to switch to a direct telephony connection with changeover bridgeport 165, steps 204 - 
206 are all performed automatically in response to step 202, without requiring any 
intervention from the user of client computer 102. In particular, it does not require the user of 
client computer 102 to enter the PSTN extension of handset 142, nor the IP address of 
changeover bridgeport 165. It does not even require the user of client computer 102 to know 
this information. All that is required of the user is the metaphorical "pushing" of the Push- 
To-Talk'^'^ button projected by web server 128. Furthermore, it should also be noted that the 
concurrence of the user of client computer 102 is not necessary. For example, in the instance 
where the direct connection will be toll free, e.g., a local call, or the changeover bridgeport 
has an "800" access number, or the toll charge is to be borne by the web server, the Push-To- 
Talk'''"'^ button may be embedded with direct connection software that automatically 
establishes a direct connection with the changeover bridgeport. 

It should also be noted that the voice connection has minimal impact on establishing 
any additional data connections with any number of web servers 120 and 128. In other 
words, client computer 102 may continue to browse webpages offered by web servers 120 
and 128, while simultaneously supporting the voice connection with handset 142 via 
changeover bridgeport 165. In addition, although there may be a number of intermediate 



wo 98/41032 23 PCT/US98/04975 

routers in Internet 150 between changeover bridgeport 165 and client computer 102, 
changeover bridgeport 165 is the only server charged with supporting both the voice 
connection and the H.323 connection, while the voice connection is transparent to the 
intermediate routers. In other words, the information exchange between changeover 
bridgeport 165, through the plurality of intermediate routers of Internet 150, to client 
computer 102 will appear as normal data packets to the intermediate routers. 

Returning now to the selection of a changeover bridgeport described in step 210, page 
bridgeport 162 selects changeover bridgeport 165 from a community of bridgeports. In one 
embodiment, page bridgeport 162 first solicits input on a number of call characteristics from 
each bridgeport member of the community. The call characteristics may include the number 
of intermediate servers (Is) required to connect client computer 102 with the responding 
bridgeport member, the toll charge (Tc) that may be incurred by placing the telephone call 
from the responding bridgeport, the bandv^dth (B) currently available on the responding 
bridgeport, the number of PSTN connections (P) supported by the responding bridgeport, 
service premiums (S), if any, charged by the responding bridgeport, and so forth. In the 
context of the example implementation, one member bridgeport may respond with an 
indication that there are no intermediaries between itself and client computer 102 which may 
provide a higher quality of service, however, given its connection point to PSTN 140, there 
may be a significant toll charge incurred in placing the telephone call to handset 142 from this 
member bridgeport. On the other hand, another member bridgeport may respond with a low 
toll charge, but with a higher number of intermediaries as the voice data will have to route 
through a large number of routers. 

In any event, for the illustrated embodiment, page bridgeport 162 calculates a Call 
Metric (CM) for each of the responding bridgeport that is representative of the bridgeports 
ability to establish and facilitate the voice call between client computer 102 and handset 142. 
Equation (1) is an example of an equation used to calculate the Call Metric for each of the 
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responding bridgeport, wherein the bridgeport with the lowest CM is determined to be able to 
provide the best all around service. It should be noted that equation (1) is merely illustrative, 
as one skilled in the art will appreciate that suitable alternative equations may be beneficially 
employed to calculate alternative call metrics. 



W W 

CM, = w,{is;)^w,{Tc;)-^-^-^^^w,{s;) (i) 



where: Is number of intermediate servers 

Tc toll charge estimate 

B available bandwidth on responding server 

P number of PSTN ports available on responding server 

S premium service charge 

W weighting factor 



In one embodiment of the present invention, the number of intermediate servers (Is) is 
determined by each of the responding bridgeports from the community of bridgeports through 
the use of a "traceroute" function, common to the UNIX network operating environment. As 
one skilled in the art will appreciate, the execution of a "traceroute" command by a bridgeport 
will produce a result quantifying the number of intermediate routers between the execution 
bridgeport and a destination address (provided in the command line). Accordingly, in one 
embodiment, the execution of the command: "traceroute (IP_address)", will return a number 
representative of the intermediate routers required for the responding bridgeport to 
communicate with the source address, represented by IP_address. 



In one embodiment, an estimate of the toll charge is determined locally at the 
responding bridgeport by accessing a toll rate table stored on the responding bridgeport. An 
example toll rate table is depicted in Table 1. As illustrated in the example toll rate table of 
Table 1, an estimate toll charge is determined by analyzing the components of the destination 
telephone number against a toll charge hierarchy. If none of the elements of the destination 
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telephone number match (i.e., hit) the elements of the toll rate table, a high toll charge 
estimate is returned. If, however, there is a hit on the area code and the telephone number 
prefix, a much lower toll charge or even toll free estimate is returned. In alternate 
embodiments of the present invention, the responding bridgeport may query the local SSP 
(i.e., the SSP to which it is coupled) to ascertain a specific toll charge value. In such a case, 
the communication between the responding bridgeport and the local SSP is conducted via an 
out-of-band signaling protocol such as Signaling System 7 (SS7). 



Elements of Destination Telephone No. 


Relative Toll Charge Estimate 


No Hit 


$ $ $ $ 


Area Code Hit 


$ $ 


Area Code and PSTN Prefix Hit 


0 



Table 1 : Toll Charge Lookup Table 



In an alternate embodiment, page bridgeport 162 may also involve client computer 
102 in the selection of a changeover bridgeport, by presenting the solicited responses to the 
client computer 102, in either an uncondensed or a condensed format. Whether client 
computer 102 should be involved in the selection process is a design choice, a trade off 
between ease of use (without requiring intervention from the user of client computer 102) and 
functionality (allowing the user of client computer 102 to veto or influence the selection). 
Between the two distinct choices, a number of alternate hybrid embodiments exist which do 
not deviate from the scope and spirit of the present invention. 

Although bridgeport 162 has been described as a page bridgeport, and bridgeport 165 
has been described as a changeover bridgeport, it should be noted that since they are both 
members of a community of bridgeports they may, at one time be a page bridgeport, while 
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serving as a changeover bridgeport at another time, or the bridgeport may simuhaneously 
server as both the page and changeover bridgeport. As will be readily apparent from the 
descriptions to follow, bridgeports 162 and 165 of the present invention can be practiced with 
computer servers programmed to perform the above described bridgeport functions, thus it is 
expected that a bridgeport may be integrated with other equipment in a variety of manners, 
for examples, with a web server, an ISP, a STP, and so forth. 

Turning now to Figures 3 and 4, two block diagrams illustrating the hardware and 
software elements of an exemplary computer server 300 suitable to be employed as a 
bridgeport are depicted. As illustrated, exemplary computer server 300 is comprised of 
multiple processors 302a - 302n and memory subsystem 308 coupled to processor bus 304 as 
depicted. Additionally, computer server 300 is comprised of a second bus 310, a third bus 
312 and a fourth bus 314. In one embodiment, buses 312 and 314 are Peripheral Component 
Interconnect (PCI) buses, while bus 310 is an Industry Standard Architecture (ISA) bus. PCI 
buses 312 and 314 are bridged by bus bridge 316, and bridged to ISA bus 310 and processor 
bus 304 by I/O controller 306. Coupled to PCI bus 312 are network interface 318 and display 
interface 320, which in turn is coupled to display 322. Coupled to PCI bus 314 is computer 
telephony interface (CTI) 324, PSTN interface 326 and SS7 Interface 328. Coupled to ISA 
bus 310 are hard disk interface 330, which in turn is coupled to a hard drive 332. 
Additionally, coupled to ISA bus 310, keyboard and cursor control device 334, which in turn 
is coupled keyboard 336 and cursor control device 338. 

CTI interface 324 provides the necessary hardware to interface exemplary computer 
server 300 to telephony equipment, such as private branch exchange (PBX) equipment. 
PSTN interface 326 provides the necessary hardware to interface exemplary computer server 
300 to a plurality of PSTN communication lines (e.g., Tl, El or POTS), wherein the actual 
number of PSTN communication lines interfaced will be implementation dependent. 
Additionally, PSTN interface 326 provides advanced DSP-based voice, dual-tone multiple 
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frequency (DTMF) and call progress functionality, which allows for downloadable DSP 
protocol and voice processing algorithms, thereby providing CODEC support locally on the 
interface. Examples of supported codecs include the Global System for Mobile 
Communications (GSM) codec and the ITU-T G.723.1 protocol codecs, the specification for 
which are commonly available from the GSM consortium and the International 
Telecommunications Union, respectively. Similarly, SS7 interface 328 provides the 
hardware necessary to interface exemplary computer server 300 with PSTN trunk lines (e.g., 
ISDN) supporting the out-of-band communication protocol (e.g., SS7)) used between PSTN 
network elements (i.e., SSP-SSP, SSP-STP, STP-SCP, etc.). In one embodiment, PSTN 
interface 326 is preferably an AG-Tl™ (for U.S. implementations, while an AG-El may be 
seamlessly substituted for European implementations), while SS7 interface 328 is preferably 
the TX3000™, both of which, along with their accompanying software drivers, are 
manufactured by and commonly available from Natural MicroSystems of Natick, 
Massachusetts. Otherwise, all other elements, processors 302*, memory system 308 and so 
forth perform their conventional functions known in the art. Insofar as their constitutions are 
generally well known to those skilled in the art, they need not be further described. 

From a software perspective. Figure 4 illustrates the software elements of exemplary 
computer server 300, In particular, exemplary computer server 300 is shown comprising an 
application layer consisting of a Bridgeport Management Driver 402, Hop Off™"* driver 404, 
and other drivers 406. Hop OfP^ driver 404, supported by Management Driver 402, optional 
drivers 406, and abstracted service layer 408 implements the method steps of Figure 2 that 
are the responsibility of the community of bridgeports (i.e., bridgeports 162, and 165). In this 
respect, a changeover bridgeport appropriate configured may be referred to as a Hop OfT^^ 
bridgeport, in view of its incorporation of Hop OfF*^ driver 404. 



* Hop OffM is a Trademark of eFusion'^'^, Incorporated of Beaverton, Oregon. 
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The Service Abstraction Layer (SAL) 408 is shown comprising SS7 services 410, CTl 
Services 411, Management Services 412, Connection Services 414, Streaming Services 416, 
and Data Services 418. The protocol/service layer is shown comprising Telephony 
Application Programming Interface (TAPI) 420, Telephony Connection Protocol 422, PSTN 
Data Interface 424, CODEC 426, Real Time (Streaming) Protocol 428, and HTTP server 434. 
Also shown in this "layer" are configuration management data 419 maintained by 
management service 412, and codec services 426 employed by streaming services 416. The 
driver layer is shown comprising SS7 driver 427, CTI driver 429, PSTN driver 430 and 
socket service 432. Data and control information are exchanged between these elements in 
the fashion depicted. 

Within the context of the present invention, one purpose of SAL 408 is to provide an 
Application Programming Interface (API) for all the available bridgeport and related services 
in exemplary computer server 300. The API abstracts out the actual modules used for 
providing services such as connection establishment (414), streaming and data exchange 
services (416 and 418). Additionally, SAL 408 provides the common operation tools such as 
queue management, statistics management, state management and the necessary interface 
between the software services (i.e., drivers in the driver layer). SAL 408 is also responsible 
for loading and unloading the appropriate drivers as appropriate. 

Connection service 414 includes a connection establishment and tear-down 
mechanism facilitating the interconnection to the PSTN 140. Additionally, for the illustrated 
embodiment, connection service 414 employs connection and compatibility services which 
facilitate interoperation between communication equipment that support industry standards, 
thereby allowing a variety of communication equipment manufactured by different vendors to 
be benefited from the present invention. Connection services 414 include, in particular, 
services for supporting standard video telephony, such as ITU-T's H.323 video telephony, 
and standard data conmiunication, such as ITU-T's T.120 data communication protocol. 
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Examples of the connection establishment and tear-down mechanisms supported by 
connection service layer 414 include opening and starting PSTN ports, call control, DTMF 
collection, and tone generation, to name but a few. 

Streaming service 416 is responsible for interfacing with the components that provide 
the real-time streaming functionality for the multimedia data. Once the connection has been 
established between the connection points (i.e., PSTN, H.323, etc.), streaming service 416 
will take over the management and streaming of data between the two connected parties, until 
the connection is terminated. CODEC service 426 facilitates the above described 
compression and transmission of inbound call signals from handset 142 as well as 
decompression and transmission of outbound call signals from client computer 102. 

Data service 418 is responsible for providing non real-time peer to peer (i.e., 
computer-computer) messaging and data exchange between exemplary computer server 300 
and other Internet and perhaps PSTN based applications. Sending messages to exemplary 
computer server end-points (i.e., other similarly equipped bridgeports on the Internet) or other 
servers within the PSTN is accomplished via data service 418. 

CTI services 411 service all communications and automatic call distribution (ACD) 
necessary for Private Branch Exchange (PBX) based systems. SS7 services 410 service all 
out of band communications with STPs and/or SCPs of PSTN 140. 

PSTN driver 430 is equipped to accommodate particularized PSTN interfaces 326, 
whereas CTI driver 429 is equipped to support particularized ACD and PBX equipment. 
Similarly, SS7 driver 427 is equipped to support particularized SS7 interface 328. 

Turning now to Figures 5, 6 and 7, graphical representations of alternate 
embodiments of a Push-To-Talk™ indicator for requesting a voice communication session, 



wo 98/41032 20 PCT/US98/04975 

suitable for use in the exemplary communication system of Figures 1-4, is shown. In Figure 
5, indicator 500 is a binary prompt embedded in the HTML information for a webpage 
projected by a web server (e.g., web server 128), and is selectively actuated by a user to 
initiate a voice connection with a PSTN extension associated with a handset. In one 
embodiment, indicator 500 is a Push-To-Talk™ button. In response to a user actuation of 
Push-To-Talk™ button 500, a prompt 502 for location information is projected to the user of 
client computer 102. In one embodiment, prompt 502 may be a pull-down selection of 
predetermined locations (e.g., city/state and country locations), wherein the user is requested 
to make a selection of a location closest to the user. In response to providing the location 
information, an additional prompt 504 may then be generated which allows the user to set the 
weighting of different characteristics associated with establishing and facilitating the voice 
connection (e.g., cost and call quality). In one embodiment, call characteristic prompt 504 
includes slide members 506 and 508 which are selectively manipulated by the user of client 
computer 102 to correspond to "weighting values" (W^) to be given to, for example, cost and 
connection quality, respectively. 

Alternatively, in Figure 6, indicator 600 is shown comprising Push-To-Talk™ button 
500 and location information prompt 502. In response to the coextensive selection of 
location information and the actuation of Push-To-Talk'''^ button 500, an additional prompt 
504 may then be generated which allows the user to set the weighting of different 
characteristics associated with establishing and facilitating the voice connection (e.g., cost 
and call quality). In the alternate embodiment of Figure 7, exemplary indicator 700 is shown 
comprising Push-To-Talk™ button 500, location information prompt 502 and call 
characteristic prompt 504. In accordance with the coextensive selection of location 
information and call characteristic information with the actuation of Push-To-Talk™ button 
500, the establishment of a voice connection is initiated in accordance with the method steps 
of Figures 2A-2c. 
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While the method and apparatus of the present invention has been described in terms 
of the above illustrated embodiments, those skilled in the art will recognize that the invention 
is not limited to the embodiments so described. In particular, the present invention may 
beneficially be implemented in combination with other technology to accommodate a wide 
variety of communication needs. For example, in one embodiment, the Push-To-Talk™ 
service instead of being offered by the corporate web server, may be offered by an 
independent third party. Accordingly, an intermediate third party server (or bridgeport) other 
than the web server may "inject" a Push-To-TalkTw button into the information exchange 
between the web server and the client computer which, when enabled, will initiate a voice call 
to the local affiliate. Just such an invention is discussed in copending U.S. Patent Application 
No. <insert patent application number>, docket number 002784.P001 entitled "Method and 
Apparatus for Value Added Content Delivery", filed contemporaneously herewith and 
commonly assigned to the assignee of the present application, the disclosure of which is fully 
incorporated herein by reference. In other communication environments, it may be beneficial 
for the user of the client computer and the user of the PSTN extension (who also has access to 
a computer) to view common information on the computer displays while maintaining the 
voice connection (e.g., a customer service, help desk, sales, etc.). A description of just such 
an invention is discussed in the U.S. patent application entitled "Method and Apparatus for 
Synchronizing Information Browsing Among Multiple Systems", U.S. Patent Application 
No. <insert patent application number>, attorney docket number 002784.P004, filed 
contemporaneously herewith and conmionly assigned to the assignee of the present 
application, the disclosure of which is fiilly incorporated herein by reference. In other 
embodiments, it may be beneficial to provide customized call processing services to the 
communication environment. Examples of such customized call processing services include 
providing an automated call attendant service having specialized call processing features. 
Just such an invention is disclosed in the U.S. patent application entitled "Method and 
Apparatus for Providing Customized Call Processing", U.S. Patent Application No. <insert 
patent application number>, attorney docket number 002784.P010, filed contemporaneously 
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herewith and commonly assigned to the assignee of the present application, the disclosure of 
which is fully incorporated herein by reference. All of the foregoing patent applications are 
expressly incorporated herein by reference. Thus, the present invention can be practiced with 
modification and alteration within the spirit and scope of the appended claims. Accordingly, 
the description is to be regarded as illustrative instead of restrictive on the present invention. 

Thus, a method and apparatus for establishing a voice call to a PSTN extension for a 
networked client computer, and for routing the call off of the network has been described. 
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Claims 
We claim: 

1 . An apparatus comprising: 

a storage medium having stored therein a plurality of programming instructions for 
implementing a set of communication services for establishing and facilitating a voice call to 
a PSTN extension for a client computer, wherein the communication services include services 
for receiving an event notification from the client computer denoting the client computer's 
acceptance of an offer by a server to establish a voice communication session, and 
determining the PSTN extension in accordance with one or more attributes of the server; and 

an execution unit coupled to the storage medium for executing the plurality of 
programming instructions. 

2. The apparatus of claim 1 , wherein 

the event notification incldues identification information of the server, and 
the communication services determine the PSTN extension in accordance with the 
identification information. 

3. The apparatus of claim 2, wherein the communication services further include 
services for accessing a geographic location service, and the communication services access 
the geographic location service to determine a suitable voice call destination. 

4. The apparatus of claim 2, wherein 

the server is a web server having a URL, 
the event notification incldues the URL of the web server, and 
the communication services determine the PSTN extension in accordance with the 
URL of the web server. 
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5. The apparatus of claim 4, wherein the apparatus further includes a database of PSTN 
extensions associated with a plurality of URLs of web servers, and the communication 
services access the database to look up the PSTN extension. 

6. The apparatus of claim 1, wherein 

the communication services further include services for providing the client computer 
with a network address of the apparatus, and receiving a supplemental voice call request from 
the client computer, including a network address and one or more attributes of the client 
computer, and 

the communication services perform said determination of the PSTN extension further 
in accordance with one or more of the included attributes of the client computer. 

7. The apparatus of claim 6, wherein the communication services further include 
services for causing a packet/voice bridging driver to be launched on the client computer. 

8. The apparatus of claim 6, wherein 

the one or more attributes of the client computer include a zip code of an area where 
the client computer is located, and 

the communication services perform said determination of the PSTN extension taking 
into consideration the zip code. 

9. The apparatus of claim 6, wherein 

the one or more attributes of the client computer include a telephone number 
associated with the client computer, and 

the communication services perform said determination of the PSTN extension taking 
into consideration at least the area code of the telephone number. 
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1 0. The apparatus of claim 1 , wherein the communication services ftjrther include 
services for soliciting inputs from one or more other apparatuses on one or more operating 
characteristics associated with establishing the voice call to the PSTN extension, selecting 
either itself or one of the otlier apparatuses to place the voice call to the PSTN extension, and 
identifying the selected apparatus to the client computer. 

11. The apparatus of claim 1 0, wherein the communication services further include 
services for registering the voice call to the PSTN extension with the selected apparatus. 

12. The apparatus of claim 11, wherein the communication services further include 
services for receiving registeration of the voice call to the PSTN extension. 

13. The apparatus of claim 1 0, wherein the communication services further includes 
services for causing a packet based telephony application to be launched on the client 
computer. 



14. The apparatus of claim 1 , wherein the communication services further include 
services for receiving a packet based phone call from the client computer, placing the voice 
call to the PSTN extension, and bridging the packet based and voice calls. 



15. The apparatus of claim 14, wherein the bridging services include services for 
converting and delivering call signals between the client computer and the PSTN extension. 



16. The apparatus of claim 1 , wherein the communication services further include 
telephony services for cooperating with telephony equipment coupled to the apparatus. 



1 7. The apparatus of claim 1 , wherein the storage medium further having stored therein 
programming instructions for implementing web server functions. 
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] 8. The apparatus of claim 1 , wherein the storage medium further having stored therein 
programming instructions for implementing internet service provider functions. 

19. A method for placing a voice call to a PSTN extension comprising the steps of: 

(a) receiving an event notification from a client computer denoting the client 
computer's acceptance of an offer by a server to establish a voice communication session, and 

(b) determining the PSTN extension in accordance with one or more attributes of the 

server. 

20. The method of claim 19, wherein 

the step of receiving an event notification incldues receiving identification 
information of the server, and 

the step of determining the PSTN extension is performed in accordance with the 
received identification information of the server. 

21. The method of claim 20, wherein the step of determining the PSTN extension 
includes accessing a directory service to look up the PSTN extension using the received 
identification information. 

22. The method of claim 20, wherein 

the server is a web server having a URL, 

the step of receiving an event notification incldues receiving the URL of the web 
server, and 

the step of determine the PSTN extension is performed in accordance with the URL of 
the web server. 

23. The method of claim 22, wherein the step of determining the PSTN extension 
includes accessing a database to look up the PSTN extension. 
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24. The method of claim 1 9, wherein 

the method further comprises the steps of providing the client computer with a 
network address of the apparatus, and receiving a supplemental voice call request from the 
client computer, including a network address and one or more attributes of the client 
computer, and 

the step of determining the PSTN extension is performed further in accordance with 
one or more of the included attributes of the client computer. 

25. The method of claim 24, wherein the method further includes the step of causing a 
packet/voice bridging driver to be lauched on the client computer. 

26. The method of claim 24, wherein 

the one or more attributes of the client computer include a zip code of an area where 
the client computer is located, and 

the step of determining the PSTN extension includes taking into consideration the zip 

code. 

27. The method of claim 24, wherein 

the one or more attributes of the client computer include a telephone number 
associated with the client computer, and 

the step of determining the PSTN extension includes taking into consideration at least 
the area code of the telephone number. 

28. The method of claim 1 9, wherein the method further includes the steps of 
soliciting inputs from one or more apparatuses on one or more operating 

characteristics associated with establishing the voice call to the PSTN extension, 

selecting one of the apparatuses to place the voice call to the PSTN extension, and 
identifying the selected apparatus to the client computer. 
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29. The method of claim 28, wherein the method further comprises the step of registering 
the voice call to the PSTN extension with the selected apparatus. 

30. The method of claim 29, wherein the method further includes the step of receiving 
registeration of tlae voice call to the PSTN extension. 

3 1 . The method of claim 28, wherein the method further includes the step of causing a 
packet based telephony application to be lauched on the client computer. 

32. The method of claim 19, wherein the method further includes the steps of 
receiving a packet based phone call from the client computer, 

placing the voice call to the PSTN extension, and 
bridging the packet based and voice calls. 

33. The method of claim 32, wherein the step of bridging includes converting and 
delivering call signals between the client computer and the PSTN extension. 

34. An apparatus comprising: 

a storage medium having stored therein a plurality of programming instructions for 
implementing a set of communication services for cooperating with a first bridging apparatus 
to establish and conduct a voice call v^th a PSTN extension, wherein the communication 
services include services for receiving an IP address of a second bridging apparatus, and in 
response, transmitting a call request for the voice call, including an IP address and other 
attributes of the apparatus for inclusion by the second bridging apparatus in determining the 
PSTN extension; and 

an execution unit coupled to the storage medium for executing the plurality of 
programming instructions. 
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35. The apparatus of claim 34, wherein the attributes of the apparatus include a zip code 
of an area where the apparatus is located. 

36. The apparatus of claim 34, wherein the attributes of the apparatus include a PSITSI 
extension associated with the apparatus. 

37. The apparatus of claim 34, wherein the communication services further include 
services for receiving an IP address of the first bridging apparatus, and lauching a packet 
based telephony application to place a packet based phone call to the first bridging apparatus. 

38. The apparatus of claim 37, wherein the first and the second bridgiing apparatuses are 
the same apparatus. 

39. A method for cooperating with a first bridging apparatus to establish and conduct a 
voice call with a PSTN extension, the method comprising the steps of: 

receiving an IP address of a second bridging apparatus, and 

in response, transmitting a call request for the voice call, including an IP address and 
one or more attributes of a host apparatus implementing the method, for inclusion by the 
second bridging apparatus in determining the PSTN extension. 

40. The method of claim 39, wherein the attributes include a zip code of an area where the 
host apparatus is located. 

41 . The method of claim 39, wherein the attributes include a PSTN extension associated 
with the host apparatus. 

42. The method of claim 39, wherein the method further includes the steps of: 
receiving an IP address of the first bridging apparatus, and 
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lauching a packet based telephony application to place a packet based phone call to 
the first bridging apparatus. 

43. The method of claim 42, wherein the first and the second bridging apparatuses are the 
same apparatus. 
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